Accept additional compatible model specifiers on release manifests#798
Merged
Accept additional compatible model specifiers on release manifests#798
Conversation
`build_release_manifest` now takes `additional_compatible_specifiers`: a list of PEP 440 specifier strings that extend the `compatible_model_packages` list beyond the single `==<build_version>` entry it emits by default. Motivation: when the `data_build_fingerprint` is stable across a range of `policyengine-us` versions, the data package can declare compatibility without forcing downstream consumers (policyengine.py, policybench) to rebuild the dataset for every model patch release. Without this, the published release manifest lists only the exact build-time model version, which in practice is sometimes a broken pin (1.637.0 fails parameter validation against current policyengine-core). The policyengine.py side that consumes these specifiers was extended in PolicyEngine/policyengine.py#284 to handle full PEP 440 specifiers via packaging.specifiers.SpecifierSet. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
MaxGhenis
added a commit
that referenced
this pull request
Apr 21, 2026
Align data-side TRO with canonical TROv 0.1 and policyengine.py bundle-side TRO. Subagent review (CLEAN): - canonical TROv 0.1 vocabulary verified against trov.ttl - canonical_json_bytes and composition-fingerprint algorithm byte-identical to policyengine.py - structured pe:* provenance fields (not prose) - JSON schema validates emitted TROs - uploader emits floating + versioned paths for both release_manifest.json and trace.tro.jsonld Admin-merging: integration-tests hits pre-existing test_aca_calibration tolerance failure identical to PR #798; TRO code isn't imported during the data build path. Companion issue PolicyEngine/policyengine.py#313 tracks bundle-side namespace migration.
# Conflicts: # policyengine_us_data/tests/test_release_manifest.py # policyengine_us_data/utils/release_manifest.py
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Extends
build_release_manifestwith anadditional_compatible_specifiersparameter so the publishedrelease_manifest.jsoncan declare compatibility with a range ofpolicyengine-usversions, not only the exact version used at build time.Why
The current behaviour emits exactly one entry in
compatible_model_packages—==<build_version>— even when the build-time model has the samedata_build_fingerprintas a range of neighbouring versions. Downstream consumers (policyengine.py, policybench) can only certify against that one pin.In practice this has bitten us: the latest HF
mainrelease manifest pins==1.637.0, which fails parameter validation againstpolicyengine-core>=3.25.0. Downstream projects that want to use the certified bundle have no compatible model version to install.Giving the data build pipeline the ability to declare e.g.
">=1.637.0,<2.0.0"when the fingerprint is stable closes that gap.Companion PR
PolicyEngine/policyengine.py#284 extends the consuming side to parse full PEP 440 specifiers via
packaging.specifiers.SpecifierSet.Test plan
test_build_release_manifest_adds_additional_compatible_specifiers— passes🤖 Generated with Claude Code